The virtualization of applications and processes is generally understood. In some cases, the virtualized environment can consumer a large number of resources based on the usage of the applications in the environment and the size or complexity of the applications. For example, a virtual machine (VM), in a virtualized environment and running a single enterprise instantiation of an application, requires dedicated memory for the application to be ready to process an event or activity. However, the timing of the events often occurs far apart, much of the time these applications may be doing little processing, but the current virtualization environments require the applications to be running to process events.
For example, in a communications application supporting 20 users, each users may generate a maximum of 20 SIP events per hour (e.g., phone calls, call forwards, no answer, etc.), resulting in 400 events per hour. If the average time to process and complete an event is 50 milliseconds, the user causes actual activity of 20 seconds for the application, resulting in actual utilization of less than 0.5%. As these types of programs need to be continually available, it is difficult to scale the number of served instances without also linearly increasing the number of resources provided for executing the programs—although the programs do not execute all the time. Thus, the problem is how to increase the elasticity of a large scale solution without resorting to a redesigned application that can partition multiple customers within a single VM instantiation.
For software modules that have a relative large static size (based on the number of applications executing and the size of the applications), most current mechanisms have low granularity and a slow response to initialization. For example, for a process that is 100 Mbytes, and if the process requires 1 hour of processing, the effective use of resources is 1 hour×100 Mbytes. So any event requiring that resource would generate 100 MBH of data storage and require the defined processing, even if it was a single event lasting 10 seconds. Also, the time to load the 100 Mbytes of data makes it challenging to load in real time to respond to requests in a sufficiently succinct manner.